Open in StackBlitz

npm i https://pkg.pr.new/rescript-lang/rescript@7531

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/darwin-arm64@7531

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/darwin-x64@7531

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/linux-arm64@7531

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/linux-x64@7531

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/win32-x64@7531

commit: a6e7595

Nice!
So this enables additional tests that were not converted to assertEqual yet but have == in their doc comments, and all those tests are passing, right?

Next steps (in separate PRs) could then be

• convert the assertEquals back to doc comments with == (checking that the same tests are still executed)
• logging warnings about doc comments in the stdlib/runtime that don't have an == check yet?

So this enables additional tests that were not converted to assertEqual yet but have == in their doc comments, and all those tests are passing, right?

Yes.

convert the assertEquals back to doc comments with == (checking that the same tests are still executed)

Yes, it would be nice to have an automatic check that the script correctly detected ==, since the parsing logic is not the most reliable. Requiring == per interface and having a warning/error for this sounds like a good solution